Computer program applications, such as user applications, are typically written to run within an operating system (OS) environment. Furthermore, such computer program applications often make use of standard/common functionality provided by, say, the OS, and its underlying software layers and hardware, in order to perform standard/common functions. Such standard functionality is typically accessible to computer program applications by way of an application programming interface (API) that is made available by the OS, whereby a computer program application simply makes a ‘function call’ into the appropriate API for accessing the required function.
In general, computer systems comprise a single processor architecture, or a symmetric multiprocessor (SMP) architecture wherein two or more identical processor cores are connected to a single shared main memory and operate under instances of a common OS. Accordingly, substantially all system resources, including all computer cores, are under the control of, or accessible via, the OS. Upon receipt of such a function call to an API, the OS reserves the required resources for executing the called function, and initialises the function to execute. The OS then passes any return parameters, etc., back to the computer program application that called the function.
Asymmetric multiprocessing (ASMP) is a known alternative approach to multiprocessor systems, whereby not all processors cores are treated as identical (even if they are physically the same). For example, one processor core may be designated as a ‘master’ processor core, with one or more further processor cores being designated ‘slave’ processor cores. An OS may be running on the ‘master’ processor core in a similar manner as, say, a single processor architecture, but with certain tasks or functions assigned to be performed by one or more of the ‘slave’ processor cores. In this manner, repetitive or time consuming tasks may be ‘outsourced’ by the OS to the slave processor cores, thereby freeing up the master core to perform other tasks. Furthermore, time critical tasks may be assigned to a slave processor core, which is able to perform the task without interruption, or tasks that require complex computation may be assigned to slave processor cores comprising dedicated hardware for performing such complex computation more efficiently than if performed purely in software.
Significantly, the slave processor core resources are located outside (in a functional and/or physical sense) of the direct control of the OS. As a result, in order for an application to access ‘outsourced’ functionality, it is necessary for the OS to communicate with software, such as a supervisory program, running on the slave processor core. Typically, such communication is achieved by treating the two processor cores as if they were separately networked computing devices, as opposed to processor cores of a single system, and using standard communication methods, for example a socket API approach based on the Berkeley socket API.
A problem with this known approach for enabling communication between ASMP processor cores is that such communication mechanisms are intended to support communication across networks and the like, rather than between processor cores within the same processing system. As a result, the establishment of such a connection, for example the establishment of a socket by each processor core, is relatively cumbersome. Furthermore, features used within such communication mechanisms, such as exception handling, are unnecessary when simply communicating between processor cores within the same processing system, and as a consequence supporting of these features significantly reduces the efficiency of the communication mechanism.
A further problem encountered when implementing asymmetric multiprocessing is that symmetric multiprocessing has been the dominant approach to multiprocessor architectures for many years. Therefore, computer program applications are typically written to run on single processor architectures or SMP architectures, whereby all system resources are under the control of the OS. Furthermore, computer program applications are rarely written without needing to account for, or use, sections of legacy code, example code, etc. In order to avoid the need to rewrite computer program applications that already exist, it is desirable to be able to use computer program applications that have been written for SMP systems on ASMP systems. However, identifying those parts of existing application code that relate to functionality to be performed by hardware outside of the control of the OS (e.g. by a slave processor core), and thus require modifying according to the communication method used, is extremely difficult since detailed knowledge of such code may not be available.